View XAPP876_3698430.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 1 ? 2009?2010 xilinx, inc. xilinx, the xilinx logo, virtex, spartan, ise, and other designated brands included herein are tradema rks of xilinx in the united states and other countries. all other trademarks are the property of their respective owners. summary this application note describes how to interface the virtex?-5 lxt, sxt, txt, and fxt devices featuring gtp/gtx transceivers to an analog-to-digital (adc) converter compliant to jedec standard no. 204a (jesd204a) serial interface for data converters [ref 1] . with some restrictions that are highlighted in the text, this application note can also be used for adc devices compliant to the older jesd204 standard. introduction the jesd204a standard describes a serialized interface between data converters and logic devices. it contains normative information to enable the implementation of designs that communicate with devices covered by the jesd204a standard. this application note discusses the implementation of a two-lane dual adc with each lane having a 14-bit resolution and running at 125 msps. it provides an overview of how to implement the serial data interface and the link protocol described in the jesd204a standard. although some implementation modes are discussed in this application note, not all possible implementation modes are provided in the accompanying reference design. the jesd204a standard describes the protocol for implementation with general high-speed serdes devices. the virtex-5 txt device contains gtx transceivers. the jesd204a standard is interpreted accordingly, and a compliant interface is delivered for gtx transceivers. figure 1 shows a comparison between the jesd204a standard and the older jesd204 standard. the implementation described in this application note is for a single device containing two converters (m), using one link of two lanes (l) connected to the fpga. for completeness, the fpga is always assumed to be a single device. application note: virtex-5 family XAPP876 (v1.0.1) february 22, 2010 virtex-5 fpga interface to a jesd204a compliant adc author: marc defossez x-ref target - figure 1 figure 1: comparison of jesd204 and jesd204a standards x 8 76_01_072309 m converter s 1 l a ne, 1 link 1 link, l l a ne s 1 link, l l a ne s s imil a r converter s one m u ltipoint link. all l a ne s a ligned. je s d204 je s d204a logic device (fpga or a s ic) m converter s m converter s logic device (fpga or a s ic)
gtp transceiver clocking XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 2 gtp transceiver clocking in all current adcs with a serial low-voltage differential signaling (lvds) interface, the sample rate of the converter determines the communication speed between the converter and the interface fpga. equation 1 can be used to calculate the ddr bit clock between the converter and the interface fpga. equation 1 for example, equation 2 determines the clock speed a 125 msps, 12-bit adc with a single serial lvds interface communicates with an interface fpga. equation 2 to increase the sample rate of the converters and still prov ide a workable lvds interface converter, manufacturers split the communication between the converters and the fpga into multiple lanes. the converter needs a precision sample clock for an alog signals. this samp le clock is used as a reference clock for high-speed transceivers built into the converter. the jesd204 standard is written so that the sample rate of the converter is called a frame clock. at the high-speed transceiver side of the converter, the frame clock is used to generate two other clocks: a character clock and a line clock. the frame clock is the converter?s sample clock. each frame clock cycle produces n data bits, where n is the resolution of the converter. these n samples are grouped into octets (bytes). the resolution of the converter can cause some oc tets to be used only partially. the transceiver uses the 8b/10b technique to transfer data. the byte arranged samples are converted to 10-bit values according to the 8b/10b valid character list. the line clock is the effective transmission clock and is therefore ten times the character clock. ta b l e 1 shows the relationship between the clocks, resolution, and channels of a converter device. this relationship is independent of multi-lane configurations and of the possible ways to pack the sampled data into octets. for example, assuming that all converters run at 80 msps, the frame clock is then 80 mhz. the data frame column of ta bl e 1 is the product of the first two columns, channels and resolution ( equation 3 ): equation 3 table 1: relationship between converter parameters and clock rates adc parameters data frame (octets) clocks channels resolution (bits) character clock (mhz) line clock (mhz) 1 12 2 160 1600 212 3 240 2400 4 12 6 480 4800 1 14 2 160 1600 214 4 3 20 3 200 4 14 7 560 5600 1 16 2 160 1600 216 4 3 20 3 200 4 16 8 640 6400 f adcbitclk sample _ clock adc _ resolution 2 --------------------------------------------------------------------------------------------- - = f adcbitclk 125 12 2 ---------------------- 750 mhz == data_frame channels resolution =
gtp transceiver clocking XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 3 the character clo ck column in ta b l e 1 is the product of the data frame and the frame clock ( equation 4 ). the frame clock in this case is 80 mhz. equation 4 the line clock is ten times the frame clock because ten characters are transmitted for every octet over the serial connection. the different methods of packing sampled data into octet boundaries and the possible gain or loss in transmission efficiency are discussed in data transport . ta bl e 1 demonstrates that for a certain combination of channels and resolution, one gtp transceiver lane is not sufficient. multi-lane converters?the same solution used for serial lvds based converters?must be used. figure 2 displays the conversion from sampled data to transmitted data. in the jedec standard, the frame clock is us ed as a reference clock to interface to the high-speed transceiver. the high-speed transceiver devices recover clock and data from the incoming data stream. therefore, it is not necessary for the converter to deliver a clock and frame signal to capture the data into the interface, as it is with lvds based solutions. only one pair of connections exists per channel between the converter and the gtp transceiver. thus, traces only have to be matched per channel. this leads to several possibilities for component, pcb, and device (apparatus) solutions: ? layout of traces between the converter and the fpga can be simplified. only two matched traces (one each for the p and n side) are needed per channel instead of the six traces (for the bit clock, frame clock, and data differential traces) required in a one-channel serial lvds-based converter. ? the converter(s) and the fpga can be placed on different pcbs. ? the converter pcb and interface fpga pcb can be assembled in different cabinets. note: refer to the skew budget number given in the jesd204a standard. several clock connection possibilities are shown in figure 3 , figure 4 , and figure 5 . figure 3 shows a setup similar to the serial lvds based converters. the converter requires a high-precision, low-jitter clock to sample the a nalog signals and delivers a digitized version of the clock for the fpga interface. x-ref target - figure 2 figure 2: conversion of sample data to transmission data character_clock data_frame frame_clock = by the fr a me clock sa mpled d a t a one fr a me 8 b/10b encoded d a t a for tr a n s mi ss ion c = control bit t = t a il bit x 8 76_02_021909 13 12 11 10 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ct
gtp transceiver clocking XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 4 the setup in figure 3 is useful when the converter and fpga are placed on the same pcb. only one clock connection to the fpga is needed regardless of the number of converter channels. inside the fpga, the reference clock is spread via dedicated routing amongst the different gtp_dual tiles ( figure 4 ). both oscillators (osc) in figure 4 must have the same frequency. when the adc has a sample clock rate below the minimum required reference clock rate for the gtp transceiver, the setup can be modified to use an oscillator runnin g at the character clock frequency. this dual-oscillator setup is a good solution for these cases: x-ref target - figure 3 figure 3: converter delivers the reference clock for the interface x-ref target - figure 4 figure 4: reference clock usage of converter and interface x876_03_012009 adc_0 adc adc_1 lane_0 lane_1 clk gen osc sync spi gtp_0 rx gtp_dual gtp_pll gtp_1 rx x876_04_012009 adc_0 adc adc_1 lane_0 lane_1 clk gen osc osc sync spi gtp_0 rx gtp_dual gtp_pll gtp_1 rx
gtp transceiver clocking XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 5 ? the converter and interface fpga are placed on different pcbs. ? the adc and fpga are placed so far apart on the same pcb that it is not possible to match the length, impedance, and other parameters. ? different converters with different but related sample frequencies are connected to one interface fpga. the phase-locked loop (pll) in each of the gtp_dual tiles of the fpga is capable of generating the correct high-speed clocks for capturing the data. the setup shown in figure 5 is useful when only one clock oscillator is used with multiple converters and one fpga. reference design the reference design uses a dual-converter device with 14-bit resolution and a sample rate of 125 msps. the additional clock specifications are: ? the sample and frame clocks are both 125 mhz. ? two lanes are used. ta bl e 1 shows that, for the required resolution and speed, a single-lane solution does not work. ? the two converters each use one lane. this is equivalent to two single-lane devices operating according to the jesd204a standard. ? a 14-bit resolution adc requires 2 octets. ? with the adc sampling at 125 mhz, the frame rate must be equal to 2octets 125 mhz = 250 mhz. because each octet is transmitted as a 10-bit word, the line rate must be 10 250 mhz = 2.5 ghz. equation 5 gives the settings for the pll inside the gtp_dual tile. equation 5 x-ref target - figure 5 figure 5: clocking solution with zero clock delay buffer x876_05_012009 adc_0 adc adc_1 lane_0 lane_1 clk gen zero delay clock buffer osc sync spi gtp_0 rx gtp_dual gtp_pll gtp_1 rx pll_clock clkin pll_clkdiv_fb div pll_clkdiv_ref -------------------------------------------------------------- - =
gtp transceiver clocking XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 6 substituting the reference design default values for pll_clock, clkin, and div gives equation 6 . equation 6 the parameters to solve for in equation 6 are pll_clkdiv_fb and pll_clkdiv_ref. pll_clkdiv_fb can be 1, 2, 3 , 4, or 5, and pll_clkdiv_ref can be 1 or 2. the ratio between the required frequency and the input frequency is 20. the numerator of equation 5 must already be multiplied by the fixed value of 5. because 20 divided by 5 is equal to 4, the only good selection for the parameters is: pllclkdiv_fb = 4 pll_clkdiv_ref = 1 the rx pma operates on both edges of the high-speed clock generated by the pll in the gtp_dual tile. therefore, the generated clock must be divided by two, as shown in figure 7 . x-ref target - figure 6 figure 6: gtp_dual tile shared pll settings x-ref target - figure 7 figure 7: pll output clock dividers 2500 125 pll_clkdiv_fb 5 pll_clkdiv_ref ------------------------------------------------------- - = x876_06_012009 mgtrefclk plldivsel_ref plldivsel_fb pllreset pllpowerdown intdatawidth = 1 (10-bit) div = 5 clkin pll_clock refclkout pll 1, 2 4, 5 1, 2, 3 4, 5 x876_07_012009 rx_0 serial clock rx_0 parallel clock clkin 1, 2, 4 x2 div 1, 2, 4 x2 div tx_1 serial clock tx_1 parallel clock the tx side of the pll is not needed other attributes: clk25_divider = 5, clkindc_b = true 1, 2, 4 x2 div rx_1 serial clock rx_1 parallel clock 1, 2, 4 x2 div 1, 2, 4 pll_rxdivsel_out_0 pll_rxdivsel_out_1 pll_txdivselcomm_out pll_txdivsel_out_0 pll_txdivsel_out_1
interface clocking XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 7 interface clocking the pll in the gtp_dual tile ensures that data can be received in the correct order. from the frame clock, the pll generates the high-speed bit clock used at data transmission as well as the clocks necessary to pass the serially received bits into the fpga logic. the gtp transceiver cannot perform all the fu nctions described in the jesd204a standard. therefore, some logic build is needed inside the fpga behind the gtp_dual tile. this logic build is also needed for the application running behind the whole interface to be able to retrieve data from storage such as block ram or distributed ram. thus, the reference clock (frame clock) supplied to the gtp transceiver must be passed to a pll or digital clock manager (dcm) inside the fpga so that clocks can be generated for the necessary logic. the pll implementation in the gtp transceiver has a direct clock output, refclkout, reflecting the input reference clock. this direct clock output of the gtp transceiver can be routed to a clock management tile (cmt) and used by the pll or one of the dcms of the cmt ( figure 8 ). gtp_dual tile parameters the parameters of the gtp_dual tile are: ? the gtp transceiver reference clock is 125 mhz or the sample clock of the adc. ? the pll_clock generated in th e gtp_dual tile is 2.5 ghz. ? the rx serial clock is half the pll clock rate because the deserializer samples on both edges of the clock. ? the parallel clock, equal to the character clock of the jesd204a standard, is 250 mhz. the clock is 250 mhz because two bytes or octets make one data frame. the pll in the clock management tile (cmt) must be set to match the character clock because the output data of the gtp transceiver rx interface is set to the byte-wise configuration mode. the input clock of the cmt_pll is a copy of the sample clock or 125 mhz. the calculations of the cmt_pll output clocks for a - 3 speed grade virtex-5 device are: f vcomax =1,440mhz f vco =f clkin (m/d) = 125 (10/1) = 1,250 mhz f out0 =f vco /o = 1,250/5 = 250 mhz f out1 =f vco /o = 1,250/5 = 250 mhz f out2 =f vco /o = 1,250/10 = 125 mhz the calculations of the cmt_pll output clocks for a -2 speed grade virtex-5 device are: f vcomax =1,200mhz f vco =f clkin (m/d) = 125 (8/1) = 1,000 mhz f out0 =f vco /o = 1,000/4 = 250 mhz f out1 =f vco /o = 1,000/4 = 250 mhz x-ref target - figure 8 figure 8: gtp transceiver and logic clocking x 8 76_0 8 _022309 mgtrefclk = converted fr a me clock clkin refclkout gtp_dual plllkdet pll_clock rx_0 s eri a l clock cmt_pll clkin clkfb r s t clk2 clk1 clk0 u s rclk u s rclk2 clk2 rx_0 p a r a llel clock
data transport XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 8 f out2 =f vco /o = 1,000/8 = 125 mhz the cmt_pll output_0 (usrclk) and output_1 (usrclk2) are the same because they are chosen for an 8-bit data output. the cmt_pll also generates the sample clock (clk2) for the application that uses the reassembled frame data. data transport the jesd204a standard describes the mapping of data for different converter setups and interface devices. these setups are possible: ? a single converter to a single-lane link ? a single converter to a multi-lane link ? multiple converters in the same device to a single-lane link ? multiple converters in the same device to a multi-lane link (used in this application note) a method of grouping sampled data into octets has been developed to provide a solution to these converter-to-interface setups. this method is referred to as f for the remainder of this application note. in many applications, the frame clock has the same frequency as the sample clock. a data sample and/or a partial sample is grouped into a frame of f octets. however, jesd204a allows more than one sample per converter to be transmitted in one frame cycle. this is represented by the number s as samples per converter per frame cycle and must always be an integer. each sample, converted to octets, is transmitted as a group of n? bits consisting of n data bits together with optional control and tail bits. additionally, tail bits at the end of the frame might be necessary to fill a whole number of octets per lane per frame cycle. the converter parameters defined up to this point are given in ta b l e 2 . single-lane format one device can contain multiple converters. the number of converters is referred to as m. the m converters all produce data samples with a length of n bits. these samples are then converted into octets and transmitted using 8b/10b encoding. figure 9 shows the mapping of data samples to octets and lane data. table 2: first set of converter parameters parameter description range f octets per frame 1?256 s samples per converter per frame cycle 1? 3 2 n converter resolution 1? 3 2 n? total number of bits per sample 1? 3 2
data transport XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 9 the mapping process occurs as follows: 1. starting with converter 0, the n-bit samples of all m converters are mapped to a linear axis until all samples have been mapped. 2. the samples are mapped to words. when the samples contain no control bits (out-of-range or other indication), the words are identical to the samples. when sample-specific control bits are available, either of these two opti ons can be done, as specified in the jesd204 standard: a. a relevant control bit is appended after the lsb of each conversion sample (cs), as shown in figure 10 . this figure shows a single-lane, four-converter, 12-bit resolution device with its required parameters. b. the control bits are grouped into a separate control word that is appended after the data samples. the first bit(s) of the control word correspond(s) to the control bit(s) of x-ref target - figure 9 figure 9: data format for a single lane x-ref target - figure 10 figure 10: single-lane converter with control bit without control word x 8 76_09_042 8 09 converter 0 all converter s h a ve a re s ol u tion n word 0 word 1 word m+cf?1 ng 0 ng 1 ng m+cf?1 octet 0 l a ne d a t a witho u t 8 b/10b encoding octet n?/4?1 octet f?1 ttt append control b it s to e a ch sa mple cf = 0 append control b it s as s ep a r a te word cf = 1 chop word s a t ni bb le b o u nd a rie s a nd a dd t a il b it s , or a dd t a il b it s a t the end filling u p to a whole n u m b er of octet s . converter 1 converter m?1 x 8 76_10_072309 d a t a [11:4] octet 0 upper 8 b it s of sa mple octet 1 lower 4 b it s of the sa mple, a control b it, c, a nd three t a il b it s , t cf = 0, no control word. c s = 1, control b it a dded to sa mple d a t a . f = 8 , octet s per fr a me. l = 1, there i s only one l a ne. m = 4, converter s in the device. n = 12, re s ol u tion. n ? = 16, 12- b it fit to a b o u nd a ry of 16 b it s . 7 ........... 4 3 ........... 0 converter 0 converter 1 converter 2 converter 3 d a t a [3:0]c ttt d a t a [11:4] d a t a [3:0]c ttt d a t a [11:4] d a t a [3:0]c ttt d a t a [11:4] d a t a [3:0]c ttt
data transport XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 10 converter 0, the next bit(s) in the control word correspond(s) to the control bit(s) of converter 1, and so on. figure 11 shows a single-lane, four-converter, 14-bit resolution device with its required parameters. 3 . the control words in a frame are indicated by a parameter named cf. cf = 0 if there is no control bit to sample the data. cf = 1 if control bits are in a separate control word. the total number of words transmitted per frame cycle is m + cf. 4. words not containing a whole multiple of 4 bits are extended to the smallest possible nibble group (a group of half octets) using tail bits. the extended words are indicated by ng in figure 9 (an example of this is shown in figure 10 ). 5. (optional) this step increases line efficiency by prioritizing it against easier data sample mapping ( figure 11 ). 6. a conversion word can be extended by control bits, tail bits, or both to a length of n? n bits, where n? is a whole multiple of 4. a. tail bits can be appended to make the total number of bits after the last step an integer multiple of 8. b. the sequence obtained is divided into octet boundaries. the result is f octets. the converter parameters defined in this section are given in ta bl e 3 . multi-lane format for a link consisting of l lanes, the mapping method described in single-lane format is used for a single lane. instead of putting all the data into one serdes lane, step 6 above spreads data over l f octets. the first f octets are transmitted over lane 0. the last f octets are transmitted over lane l ? 1. to make it possible to have a high lane efficiency, a new parameter named high density (hd) is introduced. when hd = 0, low density mode is used. this means that partial conversion words at the end of a group of f octets are avoided by adding more tail bits after the last full x-ref target - figure 11 figure 11: single-lane converter for increased line efficiency with control word table 3: additional converter parameters parameter description range m number of converters in the package 1?256 cf control word per frame clock per cycle 1? 3 2 cs control bits per sample 1? 3 t tail bit 1 x 8 76_11_072309 [13:6] [11:4] [3:0] [13:10] [5:0] [13:12] octet 0 7 4 3 0 converter 0 converter 1 [9:2] [7:0] cccc tttt [1:0] [13: 8 ] converter 2 converter 3 octet 1 octet 2 octet 3 octet 4 octet 5 octet 6 octet 7 cf = 1, s ep a r a te control word. c s = 0, no control b it to sa mple d a t a . f = 8 , octet s per fr a me. l = 1, there i s only one l a ne. m = 4, converter s in the device. n = 14, re s ol u tion. n ? = 16, 14- b it fit to a b o u nd a ry of 16 b it s .
data transport XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 11 nibble group in the group. in the high density mode (hd = 1), the conversion words might break at the frame boundary on the mapping axis. a multi-lane converter setup is shown in figure 12 . figure 1 3 shows a practical example of data-mapping in a multi-lane setup with four 14-bit converters. in this example, the device is first mapped over two lanes using the low-density method (hd = 0), and then using high-density mapping (hd = 1). ta b l e 4 defines the parameters introduced in this section. ta b l e 5 summarizes the parameters defined in ta b l e 2 , ta bl e 3 , and ta bl e 4 , together with other parameters defined by the jesd204a standard. x-ref target - figure 12 figure 12: multi-lane converter setup x-ref target - figure 1 3 figure 13: data mapping in a multi-lane setup table 4: additional parameters not defined in table 2 and table 3 parameter description range l number of high-speed lanes per package 1? 3 2 hd data packaging format, high density or low density 0, 1 x 8 76_12_042 8 09 converter 0 all converter s h a ve a re s ol u tion n a nd s sa mple s per converter per fr a me cycle word 0 word 1 word m* s +cf?1 ng 0 ng 1 ng m+cf?1 octet 0 octet n ? /4?1 octet f?1 octet (l?1)*f octet l*f?1 l a ne 0 d a t a witho u t 8 b/10b encoding l a ne l?1 d a t a sa mple 0 sa mple s ?1 sa mple 0 sa mple s ?1 sa mple 0 sa mple s ?1 ttt append control b it s to e a ch sa mple cf = 0 append control b it s as s eper a te word cf = 1 (0 < cf < = l) chop word s in ni bb le b o u nd a rie s a nd a dd t a il b it s or a dd t a il b it s a t the end filling u p to a whole n u m b er of octet s . converter i converter m?1 tt x 8 76_13_012009 cr0 [13:6] cr0 [5:0] tt cr1 [13:6] f = 4 octet s two l a ne s l a ne 0 cf = 0 config u r a tion d a t a : time octet with t a il b it s to fill u p the fr a me c s = 0 f = 4 hd = 0 l = 2 m = 4 n = 14 n ? = 16 cf = 0 c s = 0 f = 3 hd = 1 l = 3 m = 4 n = 14 n ? = 16 l a ne 1 l a ne 2 cr1 [5:0] tt cr2 [13:6] cr2 [5:0] tt cr3 [13:6] cr3 [5:0] tt cr0 [13:6] cr0 [5:0] tt cr1 [13:6] f = 3 octet s three l a ne s cr1 [5:0] tt cr2 [13:6] cr2 [5:0] tt cr3 [13:6] cr3 [5:0] tt tttt tttt
data transport XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 12 lane format conclusion several options are available to code the sampled data of the converter into bytes for transmission by high-speed transceivers. the higher the sample speeds of the converters, the less likely that a single high-speed transceiver lane is the solution. the converter manufacturer decides the number of transceiver lanes in the converter and how the data is mapped in these lanes. it is very common for a converter device to support only one data assembly implementation format (i.e., a subset of the jedec specification). the receiving interface must therefore adapt to the given device specifications. this information is available in the converter data sheet or user guide and is also transmitted by the converter at operation using the parameters shown in ta bl e 5 . if some of these parameters can be changed, the converter device will likely have an spi or i2c interface to do so. in conclusion, no single fpga interface solution applies to all adc devices. reference design the reference design uses a dual-converter device with 14-bit resolution and a sample rate of 125 msps. it has these specifications: ? sample clock = frame clock = 125 mhz. ? row 5 of ta b l e 1 shows the adc parameters, data frame, and clocks for a single-lane solution. this shows that multiple lanes are needed because the line rate is too high. ? two lanes are used. ? each of the two converters uses one lane. this gives the appearance of two single-lane devices. ? a resolution of 14 bits fits in a 16-bit boundary, or 2 octets. table 5: all link configuration parameters parameter description range field bid bank id 0?15 [ 3 :0] cf control words per frame clock cycle per link 0? 3 2 [4:0] cs control bits per sample 0? 3 [1:0] did device id 0?255 [7:0] f octets per frame 0?256 [7:0] hd high-density format 0?1 [0] k frames per multi-frame 1? 3 2 [4:0] l lanes per converter device 1? 3 2 [4:0] lid lane identification 0? 3 1 [4:0] m converters per device 1?256 [7:0] n converter resolution 1? 3 2 [4:0] n bits per sample 1? 3 2 [4:0] s samples per converter per frame cycle 1? 3 2 [4:0] scr scrambling enabled 0?1 [0] res1 reserved 0?255 [7:0] res2 reserved 0?255 [7:0] fchk checksum of all fields (mod256) 0?255 [7:0]
initial link synchronization XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 1 3 ? a control bit is used by the converter to control overflows. therefore, the frame setup appears as shown in figure 14 . ? the converter uses the multi-lane setup to synchronize the data of the two adc channels. initial link synchronization the gtp transceiver settings are configured as follows: ? the pll of the gtp_dual tile is initialized. ? the datapaths in the gtp transceiver use these settings: ? one gtp_dual tile is used. ? the data arrives in 8b/10b format. ? the data is presented at the fpga logic in 8-bit format. ? comma detection is needed for link alignment. ? channel bonding is needed to align both links. ? oversample mode is not used. lane synchronization is important to allow correct functioning. each lane must be fully synchronized and receiving valid data before the different lanes can be aligned through channel bonding, or using inter-lane alignment, as indicated by the jesd204a standard. to synchronize data between the converters and interface (fpga), the jesd204a standard requires a control line between the adc and the interface device. this control line is called sync, as shown in figure 15 . x-ref target - figure 14 figure 14: lane organization for the converter used in the reference design x 8 76_14_042 8 09 d[5:0] & c & t d[13:6] d[5:0] & c & t d[13:6] d[5:0] & c & t d[13:6] d[5:0] & c & t d[13:6] 1 fr a me = 2 ch a r a cter s /octet s /byte s l a ne_0 l a ne_1 the adc will b e us ed following the next jedec p a r a meter s et u p: adc p a r a meter s : 2 adc = m 2 14- b it = n 14 2 l a ne s = l 2 fr a me of 2 octet s = f 2 1 control bit = c s 1 no fr a me control bit = cf 0 low-den s ity mode = hd 0 bit s per fr a me = n ? 16
initial link synchronization XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 14 the sync signal has these characteristics: ? it is an active-low input to the adc device. ? only one sync input is used when one device contains multiple adcs. when multiple devices are used, it is possible to have multiple sync signals. ? it must be synchronous with the frame clock. ? it can be a single-ended or differential signal . when the frame clock is a differential signal, sync is best chosen to be differential as well. for an adc interface, the fpga controls the sync signal. when sync is pulled low, the adc device starts transmitting k28.5 characters on all lanes. the interface then synchronizes each lane so that valid k28.5 characters are detected and received. when each lane of the interface receives a minimum of four consecutive valid k28.5 characters, sync can be pulled high and the adc device stops transmitting. the jesd204a standard provides a state diagram that shows how lane synchronization must be performed. this state diagram is equivalent to the loss-of-sync (los) state machine of the gtp receiver. the interface uses the status outputs of this los state machine implemented in a gtp transceiver together with the rxbyteisaligned and rxcommadet status signals. the comma alignment and detection function of the gtp transceiver is set up to look for a k28.5 comma plus character in the incoming data stream. after the interface reset signal is released, the gtp transceiver, per rxenpcommaalign, starts looking for comma characters. when the gtp transceiver hardware detects the given comma character, it pulls rxcommadet high. when the incoming data stream is also properly aligned following byte boundaries, the rxbyteisaligned status is pulled high. at this point, at least four consecutive valid k28.5 characters should be received and detected by the los state machine. when all three status signals (rxbyteisaligned, rxcommadet, and rxbyterealign) are satisfied for one lane, the sync signal of that lane is pulled high. in a multi-lane system, all separate lanes must first be properly aligned before the global sync signal is pulled high and the interface takes the next step. x-ref target - figure 15 figure 15: the sync signaling interface chnl_1 adc device s erde s chnl_2 rx adc_2 adc_1 gtp_dual pll fpga tx rxbyte s aligned rxcomm a det rxlo ss of s ync rxbyte s realign re s ync re s et tx rx s ync s ync_out & s pi clock x 8 76_15_072309
inter-lane alignment (channel bonding) XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 15 the application running in the fpga fabric can issue a resynchronization at any time. this forces the sync signal low, and the gtp_dual tile waits for k28.5 character mode to be activated. ta b l e 6 shows the attribute settings for both channels in the gtp_dual tile used in this interface. these signals from the gtp_dual tile are monitored for both channels: ? rxbyteisalignedx: this signal is asserted when the paralle l data stream is properly aligned. ? rxcommdetx: this signal is asserted when the comma character is detected. ? rxlossofsyncx(1): this signal is as serted when synchronization is lost. these signals go to the gtp_dual tile for both channels and are controlled by logic: ? rxenpcommaalignx: assertion of this signal turns on the alignment procedure. inter-lane alignment (channel bonding) after the initial link synchronization, each lane is synchronized and receiving k28.5 control characters. next, inter-lane alignment must be performed. figure 16 shows the standard inter-lane alignment sequence for the jesd204a standard. at this point, the interface is in the state just before point a in figure 16 for these reasons: ? the monitored signals for lane synchronization are asserted several clock cycles before aligned data (k28.5 in this case) is available at the gtp rx data outputs. ? after the sync signal is made inactive by the fpga, several clock cycles elapse before the converted device stops transmitting k28.5 characters and new data is available at the rx data outputs. table 6: channel attribute settings attribute value align_comma_word_x 1 comma_10b_enable_x 1111111111 comma_double_x false mcomma_10b_value_x 1010000011 (k28.5) mcomma_detect_x false pcomma_10b_value_x 0101111100 (k28.5) pcomma_detect_x true (detects only the plus comma) rx_los_invalid_incr_x 4 rx_los_threshold_x 16 rx_loss_of_sync_fsm_x true notes: 1. in the above attributes, x is the gtp lane in a gtp_dual tile and can be 0 or 1.
inter-lane alignment (channel bonding) XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 16 when lane alignment is done and sync is made inactive, the converter starts transmitting the inter-lane alignment sequence on all lanes, as shown in figure 16 . the inter-lane alignment sequence described in the jedec specification allows any high-speed serdes to synchronize different lanes. for the gtp transceiver, the processing of the sequence must be adapted so that the built-in channel bonding logic of the gtp transceiver can be used. this logic operates as follows: 1. the different gtp transceivers where channel bonding is used must be chained. one gtp transceiver functions as a master while all other transceivers func tion as slaves. the master gtp transceiver is the reference to which the other channels are aligned. 2. channel bonding is performed on the data stored in the elastic data buffer of the gtp transceiver. this buffer is a fifo written by the received data stream after it has been parallelized and read by the gtp rx interface logic. adjusting the read pointer of all gtp transceiver components involved makes it possible to align received data. 3 . channel bonding is performed on the contents of the elastic data buffer, i.e., on 8b/10b decoded data. 4. the channels are aligned as follows: a. the master receives a channel bonding sequence (1 to 4 bytes long) and waits for a number of bytes (skew) before engaging channel bonding on the slaves. b. on the slaves, the position of the received channel bonding sequence is determined and the read pointer is modified. the skew is the maximum allowed delay between different channels and is typically part of the communication standard used. skew is needed to allow the slaves to receive the channel bonding sequence. this enables the slaves to determine the distance between the master (reference channel) and the other channels to adjust the elastic buffer read pointers. before applying the inter-lane procedure to the channel bonding feature of the gtp transceiver, the skew budget must be determined. the rx elastic buffer is 64 bytes deep. the intra-device skew given in the jesd204a standard is 2 3 ui (2. 3 8b/10b characters) for a single device and 68 ui (6.8 8b/10b characters) for a multi-device design. therefore, setting the maximum skew budget for the channel bonding at eight sequences allows coverage for single- and multi-device designs. although not really needed for operation of the inter-lane procedure applied to the channel bonding, it can be useful to calculate the length, k, of the multi-frame. the inter-lane alignment procedure is four multi-frames long, with each multi-frame being k frames long. k is a number x-ref target - figure 16 figure 16: jesd204a standard inter-lane alignment sequence l a ne s ync u s er d a t a a x 8 76_16_012009 s e q _1 s e q _2 s e q _3 s e q _4 k k k2 8 .5 s ync comm a r k2 8 .0 s t a rt of ch a nnel bond s e q d a t a s ym b ol s a k2 8 .3 l a ne alignment s ym b ol q k2 8 .4 s t a rt of link config u r a tion d a t a link config u r a tion d a t a ar ar a a r qc c kr c
inter-lane alignment (channel bonding) XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 17 between 1 and 3 2 such that the number of bytes per multi-frame is between 17 and 1,024. in bytes, this is expressed as equation 7 : equation 7 where f is the number of bytes (octets) in a frame. in this reference design, f = 2 and k must thus be between 8.5 and 512. the minimum size of k is 9 frames, and this is the size used for the reference design, as shown in figure 17 . ta b l e 7 contains the mapping of the link configuration data to bytes. as shown, the configuration data is 1 3 bytes long. an additiona l three control bytes (r, q, and a) must be added to the 1 3 configuration bytes, for a total of 16 bytes, or 8 frames. x-ref target - figure 17 figure 17: multi-frame alignment procedure as applied to the reference design (two lanes, dual 14-bit 125 mhz adc) table 7: mapping of the link configuration data to bytes byte bits 76543210 0 did[7:0] 1 bid[ 3 :0] 2 lid[4:0] 3 scr[0] l[4:0] 4 f[7:0] 5 k[4:0] 6 m[7:0] 7 cs[1:0] n[4:0] 8 n?[4:0] 9 s[4:0] 10 hd[0] cf[4:0] 11 res1[7:0] 12 res2[7:0] 13 fchk[7:0] 17 f ? k 1024 f ? ? x 8 76_17_012009 s e q _1 s e q _2 s e q _3 s e q _4 fr a me k = 9 r a r a r a r a qccccccccccccc
inter-lane alignment (channel bonding) XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 18 inter-lane alignment procedure (jesd204a) the inter-lane alignment procedure to perform channel bonding described in the jesd204a standard is done as follows: ? four multi-frames are transmitted by the converter. the number of r and a control characters must be counted to determine the start of real converter data. ? after link synchronization, all lanes contain the same inter-lane alignment procedure data and each of the multi-frames looks identical, as shown in figure 17 . it is thus absolutely necessary that all lanes are aligned to the same multi-frame sequence. the two ways to accomplish this are: ? option 1: - after sync is disabled, start looking for the first three r characters and the first two a characters on each lane. - when the third r character is detected on all involved lanes, enable the channel bonding for the master and use a channel bonding character, i.e., the r control character. - channel bonding occurs on the last multi-frame (seq_4 of figure 16 or figure 17 ). ? option 2: - program a channel bonding sequence of r and q in the gtp transceiver. - as soon as an r control character is detected, after sync is disabled, start a channel bonding operation. - channel bonding is performed on the second multi-frame (seq_2 of figure 16 or figure 17 ). option 2 is easier because it requires the least logic to be developed and implemented. ? at the same time that channel bonding occurs, the master gtp rx interface looks for a q character to register the link configuration data in distributed ram (lut ram). ? the number of a characters must be counted after all channels indicate channel alignment, as shown by the status output rxchanisaligned. three a characters indicate the start of real converter data. in the gtp_dual tile used in the reference design, gtp_0 is the master and gtp_1 is the slave. ta bl e 8 shows the attribute settings for channel bonding. ta bl e 8 : attribute settings for channel bonding gtp transceiver attribute setting description master chan_bond_1_max_skew_0 8 as defined in the skew budget calculation. chan_bond_level_0 1 chan_bond_mode_0 master chan_bond_seq_1_1_0 0 1 00011100 regular disparity, k character, r (k28.0) chan_bond_seq_1_2_0 0 1 10011100 regular disparity, k character, q (k28.4) chan_bond_seq_1_ 3 _0 0 0 00000000 chan_bond_seq_1_4_0 0 0 00000000 chan_bond_seq_1_enable_0 0011 chan_bond_seq_2_use false chan_bond_seq_len_0 2
inter-lane alignment (channel bonding) XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 19 two signals from the gtp_dual tile are monitored for both channels: ? rxchanbondseqx: this signal is asserted when rxdata contains the start of a channel bond sequence. ? rxchanisalignedx: this signal is asserted when the channel is properly aligned. these signals go to the gtp_dual tile for both channels and are controlled by logic: ? rxenchansyncx: this signal enables channel bonding only on the master gtp transceiver. this signal should be tied high for slaves. ? rxchbondo0[2:0]: this master output sh ould be connected to rxchbondi1[2:0]. ? rxchbondi1[2:0]: this is a slave input. note: the x in the signal names indicates the gtp lane in a gtp_dual tile and can be 0 or 1. figure 18 shows how the basic synchronization of the channels, the channel bonding, and the extraction of device data is performed. the re ference design hierarchy is constructed using the same setup. slave chan_bond_1_max_skew_0 8 as defined in the skew budget calculation. chan_bond_level_0 0 chan_bond_mode_0 slave chan_bond_seq_1_1_0 0 1 00011100 regular disparity, k character, r (k28.0) chan_bond_seq_1_2_0 0 1 10011100 regular disparity, k character, q (k28.4) chan_bond_seq_1_ 3 _0 0 0 00000000 chan_bond_seq_1_4_0 0 0 00000000 chan_bond_seq_1_enable_0 0011 chan_bond_seq_2_use false chan_bond_seq_len_0 2 ta bl e 8 : attribute settings for channel bonding (cont?d) gtp transceiver attribute setting description
data descrambling XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 20 note: interfaces for devices compliant to the jesd204 standard do not need to implement this inter-lane alignment logic because only one lane is supported. the manufacturer of the converter device might be compliant to the jesd204a standard for the single-la ne device. if so, at a minimum, detection and registering of the link c onfiguration data must be per formed. the moment when the real user data starts in the transmission must also must be accounted for. data descrambling after inter-lane alignment is done, real data is output on the gtp rx data ports. the scr parameter received in the link configuration data indicates whether or not the converter is using scrambled data. to turn descrambling on or off, the link configuration data must be read and interpreted by the application. if an spi or i2c interface is present, the application running in the fpga can instruct the converter to turn scrambling on or off. it is not necessary to check the configuration parameters because these reflect whether or not scrambling has been turned on. scrambling provides noise immunity by avoiding spectral peaks that can be produced when the same data octet repeats from frame to frame. these spectral peaks c an cause electromagnetic compatibility or interference prob lems in sensitive a pplications. spectral peaks also cause code-dependent dc offsets in the data converters via aliasing. scrambling also makes the spectrum data-independent. this ensures that possible frequency-selective effects on the electrical interface do not cause data-dependent errors. equation 8 shows the scrambling polynomial set by the jesd204a standard. equation 8 as described in the jesd204a standard, the parallel version of the descrambler is used. the descrambler is enabled when the link configuration parameter scr is set to 1 ( figure 19 ). the scr parameter is the most significant bit (msb) at address 3 . when the scr bit is set to zero, x-ref target - figure 18 figure 18: channel bonding and link configuration storage x 8 76_1 8 _042 8 09 rxdata = q q = k ch a r a cter ch a nnel bond s e qu ence detected when rxdata i s no longer a comm a : rxchari s comma = 0. rxdata i s 00011100 (r) a nd rxdata i s a k ch a r a cter en ab le ch a nnel bonding when the ch a nnel i s a ligned, thi s s ign a l goe s high a nd ch a nnel b onding s top s . ch a nnel b onding logic now look s for 00011100 (r) followed b y 10011100 (q). when fo u nd, the s l a ve re a d pointer i s a dj us ted. link config u r a tion p a r a meter memory s et gtp_ch a n_0 rxdata 0[7:0] rxchari s comma 0[1:0] rxchari s k 0[1:0] rxchanbond s eq 0 rxchani s aligned 0 rxenchan s ync 0 rxchbondo 0[2:0] gtp_ch a n_1 r s t wr_en a rd_en a rd_addr & & & + rxdata 1[7:0] rxchari s comma 1[1:0] rxchari s k 1[1:0] rxchanbond s eq 1 rxchani s aligned 1 rxenchan s ync 1 rxchbondi 1[2:0] 1 x 14 x 15 ++
reference design XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 21 the descrambler is bypassed. figure 19 shows one element of the descrambler. this element is repeated eight times for the jesd204a virtex-5 fpga implementation. reference design the reference design files can be download at: http://www.xilinx.com/member/jede c_jesd204a_ref_des/index.htm . the reference design checklist is shown in ta b l e 9 . x-ref target - figure 19 figure 19: implementation of a parallel descrambler with enable/bypass x 8 76_19_042 8 09 dn qn clk q s (n + 8 )q s (n + 16) q q q s (n+14) q s (n+15) byp ass /en ab le table 9: reference design checklist parameter description general developer name marc defossez ta r g e t d ev i c e v i r t ex - 5 l x t, s x t, t x t, o r f x t source code provided yes source code format vhdl design uses code/ip from existing application note, reference designs, third party, or core generator? software no simulation functional simulation performed yes (per hierarchical block) timing simulation performed no testbench format vdhl simulator software/version modelsim se 6.4 spice/ibis simulations no implementation synthesis tool/version xst, version 10.1.0 3 implementation software tools/versions used ise? software, version 10.1.0 3 static timing analysis performed yes hardware verification hardware verified the hardware was verified using a second fpga functioning as an adc. actual adc hardware was not available when the reference design was created.
reference design XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 22 reference design utilization summary ta b l e 1 0 shows the component resources for a dual-lane jesd204a adc interface design implemented in a virtex-5 fpga. figure 20 shows the directory setup of the reference design. pdf documents in the directory of the vhdl source code provide detailed schematics, help files, and simulation results of the implemented source code. these documents contain block hardware platform used for verification gtp transceiver inputs on the ml505 evaluation platform [ref 2] were used via sata connectors. a conversion board was used to convert from sata to sma. table 10: full interface device utilization summary component percentage (%) number utilized bufds 16 1 bufgs 15 5 gtp_dual 16 1 pll_adv 16 1 ramb 3 6s 3 2+1 flip-flops 1 201 luts 1 186 x-ref target - figure 20 figure 20: reference design directory setup table 9: reference design checklist (cont?d) parameter description top-level directory of the project. doc u ment a tion ab o u t the project (xl s , ppt, a nd other file s ). implement a tion of the project. s m a ll a pplic a tion a nd adc interf a ce. f u nction a l a nd timing s im u l a tion s cript s . model s im a nd do file s . directory us ed b y the s im u l a tion tool to s tore compiled/ s ynthe s ized file s . s ynthe s i s directory. cont a in s the s ynthe s ized file s for implement a tion. directory cont a ining the us er con s tr a int s file( s ). vhdl s o u rce code. s m a ll a pplic a tion to a llow implement a tion a nd te s ting of the interf a ce. adc interf a ce s o u rce code. clocking, pll, a nd needed clock bu ffer s . s cr a m b le a nd de s cr a m b le. only de s cr a m b le i s us ed. the virtex-5 fpga gtp tr a n s ceiver. block ram memory us ed to s tore the received gtp tr a n s ceiver d a t a . picobl a ze proce ss or de s ign for comm u nic a tion with the pc. provide s a cce ss to the adc s pi interf a ce a nd to the fpga drp port s of the pll a nd the gtp tr a n s ceiver. different s t a te m a chine s . link s ynchroniz a tion, l a ne a lignment, etc. x 8 76_20_042 8 09
reference design XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 2 3 diagrams that explain the details of the interface. the documents are provided to aid adapting the reference design to specific design needs and are supplementary to this application note. reference design ?systoplevel? ?systoplevel? consists of the jesd204a interface and a small application that enables the design to run on a xilinx? test pl atform such as the ml505 board. ta b l e 1 1 outlines the ?systoplevel? parameters. table 11: reference design ?systoplevel? parameter description attribute/generic c_nmbrofbuttons this is the number of buttons and defines the buttondebounce unit. c_dualgtptileloc this is the gtp_dual tile location. the generic is used at the jesdtoplevel hierarchical level. c_plladvloc this is the cmt_pll location. the generic is used at the jesdtoplevel hierarchical level. c_ramb 3 6loc_0 this is the block ram location for channel 0. the generic is used at the jesdtoplevel hierarchical level. c_ramb 3 6loc_1 this is the block ram location for channel 1. the generic is used at the jesdtoplevel hierarchical level. c_ramb 3 6loc_pb this is the block ram location for the picoblaze? processor code storage. the generic is used at the jesdtoplevel hierarchical level. c_busonewidth this is the bus width if the multiplexer is the application. c_bustwowidth this is the bus width if the multiplexer is the application. port/pin systop_clk_n/p this is the application clock. systop_gtpclk_n/p this is the reference clock of the gtp transceiver. systop_gtp_rx0_n/p this is the channel 0 data input. systop_gtp_rx1_n/p this is the channel 1 data input. systop_gtpprbsrst this is the reset for the prbs engine of the gtp transceiver. systop_syncin this is the sync request from the application to the interface. systop_onoff this is the input from a pushbutton that turns the block ram on or off. systop_reset this is the input from a pushbutton that resets the reference design. systop_gtpprbstst0/1 this dip switch input is t he prbs engine start of the gtp transceiver. systop_datoutsel this dip switch selects the channel on the outputs. systop_alive this led output indicates that the cmt_pll is working. systop_prbserr0/1 these led outputs indicate prbs errors. systop_flag this is the status of the block ram data buffer. systop_data this is the received data output. it is selected by ?systop_datoutsel.? systop_syncout this is the sync output to the adc device. systop_pb_uart_tx this is the interface controller uart output. systop_pb_uart_rx this is the interface controller uart input.
reference design XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 24 reference design ?jesdtoplevel? ?jesdtoplevel? is used as a component in the ?systoplevel? source code. this part of the reference design is the implementation of the jesd204a interface ( ta b l e 1 2 ). systop_pb_spi_clk this is the interface control spi bus for control of the jesd204a compliant adc. systop_pb_spi_cs systop_pb_spi_di systop_pb_spi_do table 12: reference design ?jesdtoplevel? parameter description attribute/generic c_dualgtptileloc this is the gtp_dual tile location. the generic is used at the jesdtoplevel hierarchical level. c_plladvloc this is the cmt_pll location. the generic is used at the jesdtoplevel hierarchical level. c_ramb 3 6loc_0 this is the block ram location for channel 0. the generic is used at the jesdtoplevel hierarchical level. c_ramb 3 6loc_1 this is the block ram location for channel 1. the generic is used at the jesdtoplevel hierarchical level. c_ramb 3 6loc_pb this is the block ram location for the picoblaze processor code storage. the generic is used at the jesdtoplevel hierarchical level. port/pin jesd_gtp_clkin this is the reference clock of the gtp transceiver. the differential clock buffer is placed on a higher hierarchical level of the design. jesd_gtp_rx0_n/p this is the channel 0 data input. jesd_gtp_rx1_n/p this is the channel 1 data input. jesd_gtp_reset this is the reset of the interface design, including the gtp transceiver module. jesd_gtpprbsrst this is the reset for the prbs engine of the gtp transceiver. jesd_mem_rdena this is the read enable for the block ram data buffer (port_b). jesd_mem_rdrst this is the reset for the block ram data buffer (port_b). jesd_mem_rdclk this is the clock for the block ram data buffer (port_b). this clock is normally an application clock. it is similar to the jesd204a application clock but with a different phase. jesd_mem_mustread0/1 this is the status out put of the self-addressing block ram data buffer. it indicates that the buffer is nearly full and a read must happen to prevent data loss. jesd_mem_flags0/1 these are eight status flags from the block ram data buffer that indicate where in the data buffer data is stored or retrieved. table 11: reference design ?systoplevel? (cont?d) parameter description
reference design XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 25 jesd_mem_dataout0/1 this is the data output from the block ram buffer. in the reference design, the data output is 24 bits wide and consists of 15 gtp transceiver status bits and 8 data bits. for a real application, the gtp transceiver status bits can be omitted by modifying the vhdl code. this allows the buffer to become deeper. jesd_gtp_intrfcena this is an enable for the application running behind the jesd204a interface. this enable goes high when all clocks in the interface are stable and the gtp transceiver and all logic is out of reset. jesd_gto_intrfcrst this is a reset signal for the application running behind the jesd204a interface. this signal is released (goes low) after all elements in the interface are out of reset. jesd_pllgtp_usrclk this is a clock from the cmt_pll in the jesd204a interface. this is the rxusrclk clock used by the gtp rx interface. jesd_pllgtp_usrclk2 this is a clock from the cmt_pll in the jesd204a interface. this is the rxusrclk2 clock used by the gtp rx interface. when the gtp transceiver is used in 8-bit data mode, this clock is equal to the rxusrclk. when the gtp transceiver is used in 16-bit data mode, this clock is half of the rxusrclk. jesd_pllgtp_clk2 this is an extra clock output of the cmt_pll. jesd_pll_aliveout this signal indicates that the cmt_pll is functioning. this is a slow pulsing (heartbeat) signal that can be used to connect to an led on the pcb. jesd_dscrmbl_bypass this input can be used to bypass the descramble module in the interface. this signal is normally controlled by the application. jesd_gtp_lnkcnfgrdena this enables the read port of the link configuration memory. jesd_gtp_lnkcnfgrdclk this is the clock for the link configuration memory. jesd_gtp_lnkcnfgrdaddr this is the address for the link configuration memory. jesd_gtp_lnkcnfgstat this is the status bit of the link configuration memory. jesd_gtp_lnkcnfgdatout this is an 8-bit link configuration data output. jesd_gtp_lanealignprocdone this is the status bit of the interface. it indicates that all lanes of the interface are aligned and that from this point onwards, normal data flows out of the interface. jesd_gtp_chanbondstrted this is a status bit indicating that channel bonding of the lanes has started. jesd_gtp_chanbonddone this is a status bit indicating that channel bonding is done. jesd_syncin this is a sync request from the application to the interface. jesd_onoff this is an input from a pushbutton that turns the block ram on or off. jesd_pb_uart_tx this is the interface controller uart output. jesd_pb_uart_rx this is the interface controller uart input. jesd_pb_spi_clk this is an interface control spi bus for control of the jesd204a compliant adc. jesd_pb_spi_cs jesd_pb_spi_di jesd_pb_spi_do table 12: reference design ?jesdtoplevel? (cont?d) parameter description
conclusion XAPP876 (v1.0.1) fe bruary 22, 2010 www.xilinx.com 26 the interface is built as a hierarchical structure of separate modules. each module can be used as a stand-alone module performing a specific task of the jesd204a standard. conclusion the gtp transceivers in the virtex-5 fpga are perfectly suited for adc devices using the jesd204a standard. this standard makes it possible to connect the fpga to high-speed adc devices with a low pin count. alignment of adc da ta is also made easier using the jesd204a standard. another advantage of using the virtex-5 fpga gtp transceivers is that one gtp_dual tile can connect a two-lane adc and dac device at the same time. a single interface solution cannot work for all po ssible adc setups and allow for all possibilities of the jesd204a standard. the supplied reference design needs to be modified or an interface built to follow the specifications of the adc device used. references this document uses the following references: 1. jedec standard no. 204a (jesd204a) serial interface for data converters http://www.jedec.org/download/search/jesd204a.pdf 2. ug 3 47 , ml505/ml506/ml507 evaluation platform user guide . 3 . ds202 , virtex-5 fpga data sheet: dc and switching characteristics . 4. ug190 , virtex-5 fpga user guide . 5. ug196 , virtex-5 fpga rocketio gtp transceiver user guide. 6. ug195 , virtex-5 fpga packaging and pinout specification . 7. ug20 3 , virtex-5 fpga pcb designer?s guide . revision history the following table shows the revision history for this document. notice of disclaimer xilinx is disclosing this application note to you ?as-is ? with no warranty of any kind. this application note is one possible implementation of this feature, applic ation, or standard, and is subject to change without further notice from xilinx. you are responsible for obtaining any rights you may require in connection with your use or implementation of this application note. xilinx makes no representations or warranties, whether express or implied, statutory or otherwise, including, without limitation, implied warranties of merchantability, noninfringement, or fitness for a particular purpose. in no event will xilinx be liable for any loss of data, lost profits, or fo r any special, incidental, co nsequential, or indirect damages arising from your use of this application note. jesd_gtpprbscntrst0/1 this resets the prbs module in the gtp transceiver. jesd_gtpprbstst0/1 this dip switch input is the prbs engine start of the gtp transceiver. jesd_prbserr0/1 these led outputs indicate prbs errors. table 12: reference design ?jesdtoplevel? (cont?d) parameter description date version description of revisions 09/18/09 1.0 initial xilinx release. 02/22/10 1.0.1 updated h ttp://www.xilinx.com/member/jedec_jesd204a_ref_des/index.htm link.

▲Up To Search▲

Price & Availability of XAPP876

	To Download XAPP876 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .